The Third Generation Partnership Project (3GPP) was formed as a collaboration agreement bringing together a number of standards bodies with the aim of standardising globally applicable technical specifications for third generation mobile systems based on evolved GSM core networks and the radio access technology Universal Terrestrial Radio Access (UTRA).
3GPP has specified a protocol known as Authentication and Key Agreement (AKA) for performing authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. UMTS AKA is specified in 3GPP TS.33.102 and is a challenge-response based mechanism that uses symmetric cryptography. AKA is typically run in a UMTS Services Identity Module (USIM), which resides on a smart card like device (referred to as a Universal Integrated Circuit Card or UICC) that also provides tamper resistant storage of shared secrets. AKA is run at registration and re-registration of a User Equipment (UE—where a UE is defined as the combination of a Mobile Station (MS) and a USIM) with its home network. AKA may be employed in 2G networks (i.e. GSM), in which case the UICC will be provisioned with both the USIM and Subscriber Identity Module (SIM) applications. In addition, it is likely that next generation architectures (including the Long Term Evolution architecture currently being standardised) will use AKA or an AKA based security protocol.
One of the key objectives of UMTS AKA is to provide for the securing of data on the link between the User Equipment (UE) and an Enforcement Point (EP) where access policy is enforced within the UMTS access network. In the case of a circuit switched connection, e.g. a voice call, this EP will be within the Radio Network Controller (RNC), and in the case of a packet switched connection it will be within the Serving Gateway Support Node (SGSN). In the case of a GSM network the EP will be within the Base Transceiver Station (BTS). In a LTE network, an EP may for example be within a User Plane Entity (UPE), with possibly multiple EPs present for a single connection. AKA achieves appropriate security levels by delivering to the access network keying material generated using a secret shared K between the USIM on the UE and the Home Location Register (HLR)/Authentication Centre (AuC). N.B. The HLR/AUC enhanced with IP Multimedia Subsystem functionality is referred to as the Home Subscriber Server (HSS).
Considering a packet switched access network, signalling associated with AKA is shown in FIG. 1, where the process is initiated by the UE (a combination of the USIM and the ME) sending an attach request to the SGSN in the access network. The SGSN then requests an Authentication Vector (AV) from the HSS in the UE's home network which in turn requests the AV from an Authentication Centre (AuC). Whilst FIG. 1 shows only the packet switched domain, it will be appreciated that the Visited Location Register (VLR) will perform functions corresponding of the SGSN functions in the circuit switched domain. Where reference is made to “SGSN” in the following discussion, it will be appreciated that the VLR will provide equivalent functionality in the circuit switched domain.
Two keys result from the UMTS AKA run, namely a cipher key (CK) and an integrity key (IK). CK and IK are generated at the HSS on the basis of a secret shared between the HSS and the USIM of the UE, and a random value RAND. The HSS also generates an expected result XRES by applying a suitable function to the shared secret and the random value. The keys, together with the RAND value, XRES and an authentication token (AUTN), are sent by the HSS to the SGSN. The SGSN forwards the RAND and AUTN values to the UE where they are delivered to the USIM. The SGSN also passes the keys CK and IK to the enforcement function in the SGSN. The USIM authenticates the HSS, and hence verifies the trust relationship between the home network and the EP, using the AUTN value. The USIM also generates the keys CK and IK using the RAND value and the shared secret. On the basis of the keys CK and IK, a secure tunnel can be established between the EP within the SGSN and the UE. This secures communication over the access network, and in particular the air interface. The USIM also generates a result RES using the shared secret and the RAND value, and returns this to the SGSN. The SGSN compares RES with XRES, and if the two agree traffic is allowed to flow through the secure tunnel.
The provision of specific applications (i.e. services) to a UE will often require that the UE be authenticated to the application server and that a secure channel be established between the UE and the application server via which delivery of a service or application can take place. One might think, for example, of the delivery of a mobile TV service, where media should only be delivered to users that have subscribed to (and paid for) the service.
3GPP Technical Specification TS 33.220 specifies the so-called Generic Bootstrapping Architecture (GBA). GBA provides a mechanism whereby a client terminal (UE) can be authenticated to a Network Authentication Function (NAF)—i.e. the service node or service provider—and secure session keys (Ks_NAF) obtained for use between the UE and the NAF, based upon keys CK and IK obtained during a re-run of the AKA procedure (this procedure should be distinguished from the initial AKA process run at registration or re-registration of the UE). A Bootstrapping Server Function (BSF) is introduced into the UE's home network, and the AKA re-run is between the UE and the BSF.
The simple network model for the GBA architecture is illustrated in the schematic diagram of FIG. 2. When a UE knows that a bootstrapping procedure is required, it will first perform a bootstrapping authentication with the BSF using the http digest AKA procedure (RFC 3310). Keys CK and IK will be agreed upon between the UE and the BSF (again, these keys must be distinguished from the keys agreed at registration or re-registration and which are used to secure the radio link). The BSF also provides to the UE a unique bootstrapping transaction identifier (B-TID). When a UE and a NAF wishes to obtain session keys from the BSF, the UE delivers the B-TID to the NAF, which the NAF then forwards to the BSF. The B-TID contains an index which the BSF uses to identify the UE and obtain appropriate NAF specific keys (Ks_NAF). The NAF specific keys are then forwarded to the NAF. The lifetime of the key material is set according to the local policy of the BSF.
AKA and GBA can both be employed to provide security to and within the so-called IP Multimedia Core Network Subsystem (IMS). IMS is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Release 5 and Release 6). IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 3 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network. Call/Session Control Functions (CSCFs) operate as SIP proxies with the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
A user registers in the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to it the address at which a SIP user identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions, which sessions would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF if an S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. It is noted that S-CSCF allocation is also carried for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF. When a registered user subsequently sends a session request to the IMS, the P-CSCF is able to forward the request to the selected S-CSCF based on information received from the S-CSCF during the registration process.
Every IMS user possesses one or more Private User Identities. A private identity is assigned by the home network operator and is used by the IMS, for example, for registration, authorisation, administration, and accounting purposes. This identity takes the form of a Network Access Identifier (NAI) as defined in RFC 2486[14]. It is possible for a representation of the International Mobile Subscriber Identity (IMSI) to be contained within the NAI for the private identity. In addition to a Private User Identity, every IMS user shall have one or more Public User Identities. The Public User Identity/identities are used by any user to request communications to other users. A user might for example include a Public User Identity (but not a Private User Identity) on a business card.
The IMS authentication procedure is described on a very high level in FIG. 4. Within the UE, AKA is handled by an IP Multimedia Services Identity Module (ISIM). The AKA protocol performs authentication of the User Equipment (UE) to the S-CSCF and vice versa, and is analogous to the AKA process described above. The Authentication Vector (AV) is obtained by the S-CSCF and is delivered to the P-CSCF via the I-CSCF. FIG. 5 illustrates how GBA may be mapped to the IMS architecture, with the BSF functionality being implemented at the S-CSCF and the P-CSCF sitting between the S-CSCF and the UE. The EP exists within the P-CSCF. This is considered in the ETSI TISPAN working group proposal 07-TD-17.